1

Innføring i avenue.quark

Mange vil bruke Web til publisering av informasjon som de oppretter i QuarkXPress Passport™-format. Dette kan gjøres på mange ulike måter. Den mest effektive måten er imidlertid å skille ut innholdet i slike QuarkXPress Passport-dokumenter fra selve dokumentene, og deretter lagre dette innholdet i et strukturert format, f.eks. XML. Deretter kan innholdet brukes på nytt, ikke bare på Web, men også i andre formater, til utskrifter, på CD-ROM eller hva det måtte være.

Hensikten med avenue.quark™ er nettopp å gjøre det enkelt å skille ut QuarkXPress Passport-innhold og lagre det i XML-format.

Med avenue.quark kan du hente ut innhold i QuarkXPress Passport-dokumenter og lagre innholdet i XML-format. Deretter kan innholdet lett brukes på nytt på en rekke ulike måter, også på Web. Denne delen inneholder en oversikt over framgangsmåter og definisjoner. Deretter følger mer detaljerte beskrivelser i de neste seksjonene.

Innhold er den informasjonen som gjør dokumentene verdifulle. I et tidsskrift omfatter innholdet gjerne artikler, fotografier, intervjuer og diagrammer.

En annen måte å definere innhold på, er å beskrive hva det ikke er. Topptekst, bunntekst og merknader som «Fortsetter på side x», regnes vanligvis ikke som en del av innholdet i et tidsskrift. Slike elementer utgjør i stedet tidsskriftets presentasjon, og elementene er bare aktuelle når tidsskriftet presenteres i trykt format. Presentasjonen kan variere avhengig av hvilket medium informasjonen publiseres i, mens innholdet vanligvis står uendret.

Med avenue.quark kan du skille innholdet fra presentasjonen ved å hente ut innholdet i QuarkXPress Passport-dokumentene og lagre det i XML-format. Deretter kan du presentere samme innhold på forskjellige måter, det være seg på trykk, på Web, CD-ROM eller lignende. på følgende måte trenger du bare å justere presentasjonen for hvert medium.

XML står for «Extensible Markup Language». XML er et hjelpemiddel du kan bruke til å spesifisere innholdsstrukturen og merke elementene i det aktuelle innholdet på en fornuftig måte.

Merking av innhold

Hvorfor er det nødvendig å merke innholdet? Fordi selv om vi vet at en bestemt tesktlinje i et blad utgjør en overskrift, er det ikke like lett for en datamaskin. Med XML kan du «kode» informasjon på en slik måte at datamaskiner kan gjøre bruk av den. Når datamaskinen har registrert at en tekstlinje skal utgjøre en overskrift, kan den automatisk formatere linjen som en overskrift.

Når du merker en del av innholdet i XML, setter du inn en XML-startkode foran innhold og en XML-sluttkode etter innholdet. Eksempel:

Her kan du se at en startkode består av et elementnavn mellom < og >. En sluttkode er akkurat lik, men med / etter <. I dette eksempelet har vi «kodet» teksten «Internett vokser med 400 %» som en overskrift ved å sette teksten mellom en start- og sluttkode av typen <overskrift>.

Strukturidentifisering

Vi vet at en nyhetsartikkel som regel består av en overskrift, en linje med navn på artikkelforfatteren («signaturlinje»), brødtekst og fotografier eller diagrammer med tekst. Dette vet imidlertid ikke datamaskinene før du forteller dem det.

XML gjør det mulig å beskrive oppbygningen av dokumentene med DTD-er, eller dokumenttypedefinisjoner. En DTD angir at informasjonen i et dokument skal bruke et bestemt kodesett og strukturregler. En DTD til en nyhetsartikkel kan f.eks. angi følgende:

• Hver artikkel skal ha bare én overskrift, <overskrift>.
• Linje med navn på artikkelforfatter, <forfatternavn>, er valgfritt
• Hver artikkel skal ha minst ett avsnitt, <avsnitt>.
• Alle artiklene kan ha null eller flere illustrasjonselementer, <illustrasjon>.
• Hver illustrasjon skal ha etterfølges av en billedtekst, <billedtekst>.

Ved å holde seg til reglene i en DTD, kan organisasjoner sørge for at alle dokumentene alltid struktureres på en forutsigbar og konsekvent måte. Dermed blir det langt lettere å flytte innhold fra ett medium til et annet, f.eks. fra utskrift til Web eller omvendt.

I avenue.quark er det en forutsetning at du bruker DTD-er. Hvis du vil vite hvordan du lager og tilrettelegger DTD-er, kan du slå opp under «Bruk av DTDer» og «Standard DTD-er» i dette kapitlet.

Et «nøytralt» format

XML er et «nøytralt» format i den betydningen at det ikke inneholder noen formateringsinformasjon. Formatet kan derfor brukes sammen med en rekke ulike programmer, som igjen kan brukes til å formatere innholdet på forskjellige måter når innholdet presenteres i ulike media.

XML omtales i mer detalj under «Mer om XML» i dette kapitlet.

Etter at du har skilt ut innholdet fra et QuarkXPress Passport-dokument, kan innholdet brukes på en rekke ulike måter. Du kan for eksempel foreta en dynamisk oversettelse av XML-kodet innhold til HTML-format og legge det ut på Web. Konvertering av QuarkXPress Passport-innhold til HTML på følgende måte er langt å foretrekke framfor enkel HTML-eksport, fordi innholdet nå lar seg formateres, omformateres og omorganiseres på en enkel måte.

Nå når du har dannet deg et generelt bilde av avenue.quark og hvordan det fungerer, skal vi ta en nærmere titt på det. La oss starte med XML.

XML («Extensible Markup Language») er en måte å angi dokumentstrukturen på, og bestemte elementer i innholdet merkes med koder. De strukturelle kontrollene til XML gjør det mulig å sikre at alle de nødvendige delene i dokumentet er tatt med, og at de står i riktig rekkefølge. Merking av innhold gjør det lettere for andre programmer å bruke eller vise det aktuelle innholdet.

Men la oss se litt på hvorfor dette er nødvendig, før vi viser hvordan XML gjør det mulig.

XML kommer fra et eldre og mer komplisert kodespråk kalt SGML («Standard generalisert merkespråk»). XML ble laget i den hensikt å løse ulike problemer i den forbindelse. Noen av disse problemene ble opprinnelig løst i SGML, mens andre var nye.

Tilordning av struktur og merker til informasjon

XML betegnes av og til som et «meta-språk» fordi det lar deg definere tilpassede kodespråk til bestemt bruk. Dette gjøres ved å lage en DTD (dokument-typedefinisjon). En DTD angir hvilken type informasjon som skal tas med i et dokument, hvordan de ulike delene i dokumentet skal kodes (merkes), i hvilken rekkefølge elementene skal stå og hvor mange det er lov å bruke av hvert element. Et dokument anses bare for å være «gyldig» i henhold til en gitt DTD så lenge dokumentet følger reglene til den aktuelle DTD-en.

Med DTD-er kan du sørge for at alle dokumenter har samme struktur. Hvis du har DTD-en til et dokument, vet du hva du kan vente å finne av informasjon når du åpner dokumentet. DTD-er gjør det også lettere for datamaskiner å behandle informasjonen i XML-dokumenter. Hvis en datamaskin «forstår» en DTD, kan den også «forstå» informasjonen i alle XML-dokumenter som følger denne DTD-en. Når en datamaskin får tilgang til DTD-en til et dokument, kan du f.eks. bruke datamaskinen til å søke etter alle forekomster av en bestemt type informasjon i dokumentet (f.eks. et firmanavn), eller lage en HTML-side som viser en oversikt over alle forekomtsene av den samme informasjonen (f.eks. en liste over firmanavn).

Det er allerede utviklet spesialiserte DTD-er som er beregnet på kjemiske og matematiske formål, teknisk dokumentasjon og til og med skjønnlitterært arbeid. Mulige bruksområder omfatter arbeidsflytkontroll, programvarespesifikasjoner og nesten alle andre områder som innebærer utveksling av strukturert informasjon.

Bare en liten bemerkning: I motsetning til SGML kan du bruke XML til å lage «godt formulerte» dokumenter, dvs. dokumenter som følger XML-reglene uten å følge en bestemt DTD. Det er imidlertid vanskelig å være konsekvent i alle dokumenter hvis du ikke har en standard å holde deg til. Av den grunn er det en forutsetning å bruke DTD-er i avenue.quark.

HTML

HTML har vist seg å være et kraftig og allsidig format til visning av informasjon på World Wide Web. Språket har imidlertid to ulemper: Det beskriver kun formateringen av data, og ikke betydningen, og du kan ikke lage nye HTML-koder.

XML løser begge disse problemene. Hvis du bruker XML til å merke data i et XML-dokument, kan du basere HTML-formateringen på disse merkene. La oss for eksempel si at du har et XML-dokument som inneholder en liste over firma og litt informasjon om hvert av disse firmaene. Hvis du skal gjøre listen om til en HTML-side på Web hvor alle firmanavn er skrevet med halvfet skrift, bruker du bare et program som konverterer XML til HTML, og forteller konverteringsprogrammet at alle linjer som er merket med <firmanavn>, skal gjøres om til halvfet skrift. på følgende måte er det ikke lenger nødvendig å gå gjennom dokumentet og formatere firmaets navn og adresse manuelt. Dette innebærer at personer som lager Web-sider, kan spare enormt med tid.

Informasjonsutveksling

Siden dataprogrammer er utviklet av mange ulike personer og organisasjoner og til mange ulike formål, lagrer programmene informasjon i en rekke ulike formater. To ulike firmaer lagrer for eksempel sin kundeinformasjon i to helt ulike formater, selv om selve kundeinformasjonen som firmaene lagrer (navn, adresse, telefonnummer osv.), i utgangspunktet er identisk.

XML løser dette problemet med et standardisert, fellesformat til overføring av informasjon mellom programvare. XML ble utviklet, forbedret og godkjent av et team fra ulike bransjer som arbeidet sammen under paraplybetegnelsen World Wide Web Consortium (W3C). Spesifikasjonen er tilgjengelig for alle interesserte (se www.w3.org), og mange organisasjoner og næringer har alle-rede tatt den i bruk.

Hvis to firmaer blir enige om å bruke programvare som kan konvertere arkivene deres til XML med en DTD som begge er enige om, kan de utveksle disse arkivene seg imellom, uten å risikere å miste data på grunn av inkompatible formater. Hvis du vil vite mer om DTD-er og informasjonsutveksling, se under «Standard DTD-er» i dette kapitlet.

XML omtales i mer detalj under «Bruk av XML» i dette kapitlet.

Et XML-dokument inneholder strukturert data som er oppstykket i «elementer», og hvert element beskrives med XML-koder.

Et XML-element inneholder et lite stykke informasjon, f.eks. et firmanavn, en overskrift eller et varenummer. Du lager et element ved å sette et stykke informasjon mellom to XML-koder: en startkode som inneholder navnet på elementet mellom et mindre-enn-tegn og et større-enn-tegn, og en sluttkode som er helt lik, bortsett fra en ekstra skråstrek (/) foran elementnavnet. Et kodet element for «navn» kan f.eks. se slik ut:

Det er viktig å være klar over forskjellen mellom et XML-element og en XML-kode. XML-koder er bare koden som festes til en informasjonsdel, mens XML-elementer omfatter både informasjonsdelen og kodene som omslutter informasjonen.

Med XML-koder kan du beskrive og tilføye struktur til informasjonen kodene omgir. Dette innledende avsnittet er for eksempel kodet med <innledning>-koden:

Inni <innledning>-elementet kan du kode andre underelementer for å strukturere dokumentet enda mer:

Syntaks er viktig med XML-koder. I motsetning til HTML-koder skilles det mellom store å små bokstaver; koden <Navn> er ikke den samme som <navn>, som igjen er forskjellig fra <NAVN>. Hvert XML-kodenavn må begynne med en bokstav eller understreking (_), mens de påfølgende tegnene i navnet kan være bokstaver, understrekinger, tall, bindestreker eller punktum. Det er ikke mulig å bruke mellomrom eller tabulatortegn. XML-kodenavnet <_.dir> er for eksempel riktig konstruert, mens <_ dir> og <.dir> ikke er gyldige. Kodenavnet <_ dir> kan ikke brukes fordi det inneholder et blanktegn (et tabulatortegn eller mellomrom) etter understrekingen. Kodenavnet <.dir> er derimot feil fordi det begynner med punktum i stedet for understreking eller bokstav.

Det er nyttig å være klar over forskjellen mellom «elementer» og «elementtyper». Du kan tenke deg at en elementtype er et bestemt kodenavn som kan brukes på data. Et element, derimot, er data og kodene som omgir dataene. Et dokument som inneholder en liste med navn og adresser, bruker kanskje bare to elementtyper, <navn> og <adresse>, men hundrevis av elementer bruker disse kodene.

La oss si at du jobber med elementer som er kodet med <bil>, og du vil gjerne spesifisere mer informasjon om hvert <bil>-element du lager. Du vil ikke bare betegne et bestemt <bil>-element som en bil, men også som en rask, rød og dyr bil.

Dette kan gjøres på flere måter. En av framgangsmåtene innebærer bruk av ekstra elementtyper, som i dette eksempelet:

En annen (og kanskje «ryddigere») måte å gjøre dette på, er å bruke en XML-funksjon kalt attributter. Hensikten med attributter er å gi informasjon om et element. De tas med i startkoden til et element, slik at det aldri er tvil om hvilket element de tilhører.

Et attributt består av et attributtnavn etterfulgt av et likhetstegn, som deretter følges av en attributtverdi i anførselstegn. Her bruker for eksempel følgende enkeltstående element tre attributter for å gi samme informasjon som i eksempelet ovenfor:

Attributter er nyttige av flere grunner. De gjør det for eksempel enkelt å søke i et dokument og lage en liste over alle <bil>-elementene som inneholder verdien «dyr» i prisattributtet. De er også nyttige sammen med tomme elementer. Dette kan du lese mer om i neste avsnitt.

Tomme elementer omfatter en startkode og en sluttkode som ikke omgir noen data, slik som i dette eksempelet:

Siden tomme elementer ikke har noe innhold mellom kodene i tomme elementer, blir start- og sluttkodene ofte slått sammen på følgende måte:

Du kan bruke attributter sammen med tomme elementer når du vil referere til URL-er eller filer som er lagret eksternt. Dette tomme elementet kan for eksempel brukes (sammen med en tilhørende XML-tolk) til å vise et bilde av en bil:

Vær oppmerksom på at tilføying av et attributt kalt «URL» til et element, ikke garanterer at det gis tilgang til URL-en når XLM-filen behandles. Programmet som behandler filen, må vite hva URL-attributtet skal brukes til.

I likhet med HTML kan du også sette inn kommentarer i en XML-fil. Kommentarene avgrenses av <!-- og -->, og blir stort sett ignorert av XML-behandlere. Når du for eksempel skal sette inn en kommentar om status til et <adresse>-element, kan du derfor gjøre slik:

I HTML blir kommentarer ofte brukt til spesielle kommandoer beregnet på lesere og andre HTML-behandlere. I et forsøk på å begrense bruk av XML-kommentarer til sin opprinnelige funksjon, nemlig som kommentarer, har forfatterne av XML-spesifikasjonen tatt med en metode for innsetting av spesialkommandoer i XML-filer og DTD-er. Slike spesialkommandoer, såkalte behandlingsinstruksjoner (eller «PI» ­ «processing instructions»), settes ganske enkelt mellom <? og ?>. De starter med et programnavn etterfulgt av et mellomrom og deretter eventuell informasjon som kan være av interesse for det navngitte programmet. Behandlingsinstruksjoner kan brukes alle steder der det finnes kommentarer.

Alle XML-dokumenter kan og bør starte med en XML-deklarasjon. I likhet med behandlingsinstruksjoner settes XML-deklarasjoner mellom <? og ?>. Her er et eksempel på en XML-deklarasjon:

Attributtet «versjon» erklærer at dette dokumentet oppfyller reglene for XML 1.0. Attributtet «frittstående» angir at alle kodedeklarasjoner som er nødvendige for å behandle dette XML-dokumentet, er tatt med i dokumentet.

En entitetsreferanse er et ord som fungerer som stenografi for et tegn, en streng eller en fil. Hvis du for eksempel lar entitetsreferansen &lt; representere mindre-enn-tegnet (<) i innholdet i et XML-dokument, unngår du sammenblanding i XML-syntaksanalysatoren (som ellers ville ha feiltolket «<»-tegnet som starten på en kode). Hvis du vil vite mer om entitetsreferanser, se under «Enhetsreferanser» i avsnittet «Bruk av DTD-er» i dette kapitlet.

For at et XML-dokument skal være godt formulert, kan og bør det starte med en XML-deklarasjon og ha et rotelement som inneholder alle de andre elementene (<artikkel> i det følgende eksempelet). Et XML-dokument som er godt formulert, forutsetter også at alle elementer i dokumentet har en tilhørende sluttkode. Her er et eksempel på et godt formulert XML-dokument:

Nyttighetsgraden av et godt formulert XML-dokument kan begrenses, med mindre dokumentet også er gyldig. Et XML-dokument anses for å være gyldig når det overholder spesifikasjonene i for en bestemt DTD. Hvis du vil vite mer om DTD-er og bekrefting av XML-dokumenter, se «Mer om DTD» i dette kapitlet.

En XML-behandler er ganske enkelt et program som leser en XML-fil og gjør noe med filen. Det finnes ulike typer XML-behandlere. Noen XML-behandlere konverterer kanskje en XML-fil til en HTML Web-side, en PDF-fil eller en PostScript-fil. Andre leser kanskje innholdet i XML-filen høyt eller konverterer innholdet til blindeskrift. Enkelte XML-behandlere brukes kanskje også til å kopiere strukturert XML-innhold til en database.

XML-syntaksanalysatorer

En XML-syntaksanalysator gjenkjenner XML-reglene og kontrollerer at et XML-dokument er godt formulert. Det er imidlertid ikke sikkert at XML-syntaksanalysatorer kontrollerer at et XML-dokument er gyldig i henhold til den tilhørende DTD-en. Til dette trenger du en bekreftende XML-syntaksanalysator (se nedenfor).

Bekreftende XML-syntaksanalysatorer

Bekreftende XML-syntaksanalysatorer sammenligner et XML-dokument med en DTD for å kontrollere hvorvidt dokumentet følger reglene for DTD-en. En god, bekreftende syntaksanalysator gir også konstruktiv tilbakemelding om eventuelle problemer den finner i XML-filen. Hvis du vil vite mer om XML-syntaksanalysatorer, se under «Mer om DTD» i dette kapitlet.

Hvis du trenger en kort oversikt over XML-funksjoner og -konvensjoner, kan du slå opp i tillegg A, «Grunnbegreper om XML», i kapittel 7, «Tillegg».

En DTD («Document Type Definition», dokumenttypedefinisjon) spesifiserer hvilke elementer en XML-fil kan ha, og hvordan disse elementene skal struktureres. Det er ikke nødvendig at XML-dokumenter har en tilhørende DTD; så lenge en XML-fil følger grunnleggende XML-syntaks, regnes filen å være «godt formulert» og kan leses av et XML-program. XML-filer anses imidlertid ikke å være «gyldige» uten at de følger reglene for en bestemt DTD.

DTD-er er viktige fordi de sørger for en pålitelig, godt dokumentert struktur for XML-dokumenter. Uten DTD-er er det mulig at to samarbeidende organisasjoner velger å strukturere og kode sine XML-dokumenter på to helt ulike måter. Dermed beholdes datalagrene i de to organisasjonene med ukompatible formater, selv etter at begge har gått over til å bruke XML. Hvis de to partnerne derimot bruker samme DTD ­ kanskje en DTD som de har utviklet i fellesskap, eller en DTD som er standard i den aktuelle bransjen ­ kan de utveksle informasjon på en enkel og forutsigbar måte.

Det finnes to typer DTD-er: eksterne og interne.

Teknisk sett består en DTD av listen med kodedeklarasjoner (elementdeklarasjoner, attributtdeklarasjoner, entiteter, merknader, behandlingsinstruksjoner og kommentarer) som en DOCTYPE-deklarasjon refererer til. Det som betegnes som «eksterne DTD-er» og «interne DTD-er» i dette dokumentet, er ikke fullstendige DTD-er, teknisk sett. Det er imidlertid en praktisk og ganske vanlig måte å betegne dem på.

Eksterne DTD-er

En ekstern DTD (eller eksternt delsett) er en fil som inneholder en liste med kodedeklarasjoner. Det er lett å dele eksterne DTD-er mellom XML-dokumenter og organisasjoner. Når du skal bruke en ekstern DTD i en XML-fil, henviser du ganske enkelt til DTD-en i begynnelsen av XML-filen, i følgende eksempel:

Interne DTD-er

En intern DTD (eller internt delsett) er faktisk inkludlert i XML-filen den definerer. Hvis du skal bruke en intern DTD i en XML-fil, tilføyer du den ganske enkelt i begynnelsen av XML-filen, i følgende eksempel:

Hvis et dokument bruker en ekstern DTD (eller en hvilken som helst annen ekstern entitet), skal det «frittstående»-attributtet i den første linjen vise «nei». Du finner flere opplysninger om dette under «Bruk av entitetsreferanser» i dette kapitlet.

Kombinasjon av interne og eksterne DTD-er

Du kan spesifisere en ekstern DTD og deretter tilsidesette denne eller sette inn tilføyelser til DTD-en ved hjelp av en intern DTD i et hvilket som helst XML-dokument. Her er et eksempel på hvordan et slikt XML-dokument kan se ut:

Det er nok ikke lurt å sette seg ned og begynne å skrive en DTD helt uten videre. Skal det gjøres riktig, må det betydelig planlegging til.

Før du begynner å skrive din egen DTD, bør du vurdere å bruke en av DTD-ene som er blitt standard i bransjen. Du kan lese mer om dette under «Standard DTD-er» i dette kapitlet.

Det kan være lurt å starte med å finne ut hva du vil at DTD-en skal utføre. Først bestemmer du deg for hvilke elementer du vil bruke. Hvis du har tenkt å bruke elementer som f.eks. <adresse>, bør du vurdere om disse elementene skal deles inn i underelementer, f.eks. <gateVei>, <leilighetnr>, <bySted>, <stat> og <postnummer>. (Tenk deg godt om før du forkaster ideen om en slik oppdeling; dette kan være nyttig hvis det senere kan bli aktuelt å overføre innholdet i XML-filene til en database.)

Det var den lette fasen av planleggingen. Nå må du finne ut av forholdet mellom alle disse elementene. En DTD kan angi hvilke elementer som er tillatt, i hvilken rekkefølge de skal stå og hvilke (og hvor mange) underelementer de kan ha. DTD-en kan også spesifisere hvilke andre elementer som kan omfatte et spesielt element, og den kan spesifisere hvorvidt et spesielt element må inneholde data.

I boken XML: Extensible Markup Language anbefaler Eliotte Rusty Harold at du bruker en tabell til å finne ut av forholdene mellom de ulike elementene i DTD-en. Tabellen bør ha følgende kolonner (data i kolonnene er bare ment som eksempler):

Hver rad i tabellen skal representere et element som du vil bruke i DTD-en.

I likhet med en XML-fil består også en DTD av ren tekst. En XML-fil kan brukes helt uten DTD, med en ekstern DTD, en intern DTD eller med både en ekstern og intern DTD.

Uansett hvilken type DTD som brukes i et XML-dokument, må dokumentet omfatte selve DTD-en eller en henvisning til DTD-en i forordet (innledningen), like etter XML-deklarasjonen og før brødteksten i XML-dokumentet. DTD-delen starter med «<!DOCTYPE rotnavn [» og avsluttes med «]>». Her er et eksempel på et fullstendig XML-dokument som inneholder en fullstendig DTD (med halvfete typer):

La oss se litt nærmere på dette eksempelet:

• Rotnavnet (ordet etter <!DOCTYPE) angir rotelementtypen til XML-filen.
• Hakeparentesen angir og omslutter den interne DTD-en.
• «<!ELEMENT ordtak ANY>» definerer en elementtype kalt «ordtak». «!ELEMENT» betyr «Følgende er en elementtypedeklarasjon». Deretter kommer navnet på elementet («ordtak») og informasjon om hva dette elementet kan inneholde (i dette tilfellet «ANY», som betyr både tekst og andre elementer).

Som du ser, spesifiserer hver elementtypedefinisjon både navnet på elementet og hvilken type data elementet kan inneholde. Hvis du ville endre elementtypedefinisjonen for <ordtak>, slik at det bare kan inneholde tekst (og ikke andre elementer), kan du oppnå dette ved å bytte ut nøkkelordet «ANY» med «(#PCDATA)», i følgende eksempel:

I de fleste tilfeller er det imidlertid ikke lurt å gjøre det på denne måten, fordi det betyr at dokumentets rotelement bare kan inneholde analysert tegndata (se merknad nedenfor). Du kan med andre ord ikke legge til flere elementer for å dele inn informasjonen i mindre enheter.

«PCDATA» står for «parsed character data» (analysert tegndata), dvs. tekst som kan bestå av entitetsreferanser, kommentarer og behandlingsinstruksjoner.

La oss ta en titt på en mer realistisk DTD. Denne interne DTD-en definerer strukturen for en katalog over distriktskontorer:

Legg merke til at vi har satt inn en kommentar om at <distriktsKontorKatalog> er rotelementet i DTD-en. Dette gjorde vi fordi en DTD ikke uten videre kan tilordne et rotelement; teknisk sett er det !DOCTYPE-linjen i et XML-dokument som skal spesifisere rotelementet. Det kan imidlertid være lurt å oppgi rotelementet med en kommentar, slik at personer som bruker DTD-en kan se hva de er.

I noen DTD-er kan rotelementet inneholde mer enn ett element. Du kan for eksempel skrive en DTD med definisjoner for håndboks-dokumenter og OSS-dokumenter, og deretter bruke denne DTD-en til å lage begge dokumenttypene ved å spesifisere <whitePaper> eller <OSS> som rotelementet for hver XML-fil.

Resten av linjene i DTD-en erklærer elementer for hvert kontors gateadresse, by, delstat, postnummer, land, telefonnummer, telefaksnummer og e-post-adresse.

Det er mulig at DTD-en ovenfor er alt du trenger, men den utnytter egentlig ikke alle funksjonene i XML. Definisjonen spesifiserer for eksempel ikke noen måte å ordne hvilke adresseelementer som hører med de enkelte kontorene, og den fastsetter ingen bestemt rekkefølge for informasjonen. Du kan med andre ord lage et dokument med en oversikt over alle de forskjellige byene, gatene, telefonnumrene og så videre i vilkårlig rekkefølge, og dokumentet ville likevel være gyldig i henhold til denne DTD-en.

For at DTD-en skal ha en anvendelig struktur, bør alle komponentelementene for hver oppføring føyes sammen og ordnes i en bestemt rekkefølge. En måte å gjøre dette på er å lage et beholderelement som den relevante informasjonen for ett kontor kan samles i (vi kaller det <distriktsKontor>), og deretter angi hvilke underlementer som skal utgjøre dette beholderelementet, og i hvilken rekkefølge underelementene skal stå i. Alt dette kan gjøres ved å tilføye én linje til DTD-en (med halvfete typer):

Dette nye elementet sier nå følgende: «Hvis dokumentet inneholder et element kalt <distriktsKontor>, må dette elementet inneholde nøyaktig ett av hvert av følgende elementer i denne rekkefølgen, og ingenting annet».

Hva skjer hvis adressen til ett av distriktskontorene har en gateadresse på flere linjer? Du kan gjøre det mulig med en eller flere forekomster av et hvilket som helst element i en liste med underelementer ved å sette et plusstegn + like etter navnet på elementet. Hvis du for eksempel vil tillate ett eller flere <gateAdresse>-elementer under <distriktsKontor>-elementet, kan du gjøre følgende:

Kan det tenkes at noen av distriktskontorene ikke har en telefaksmaskin? Andre kontorer har kanskje mer enn én maskin? I så fall setter du en stjerne (*) like etter navnet på elementet for å angi null eller flere forekomster av et element:

Kanskje noen av distriktskontorene ligger i land der postnumre ikke brukes. Da kan du sette et spørsmålstegn like etter navnet på elementet for å angi ingen eller én forekomst av et gitt element, i følgende eksempel:

Det som i USA kalles for «delstat» heter sannsynligvis noe helt annet på andre steder. Canada er f.eks. delt inn i provinser. Hvis du har kontor både i USA og Canada, kan det være aktuelt å tilby valg mellom <delstat>-element eller <provins>-element. Dette kan du oppnå ved å sette de to valgene i en parentes, og skille dem fra hverandre med vertikalstrek-tegnet | i følgende eksempel:

Til slutt kan vi sørge for at en <distriktsKontorkatalog> ikke inneholder annet enn oppføringer for <distriktsKontor> ved å endre definisjonen <distriktsKontorKatalog> fra ANY til (distriktsKontor*). Da ser det ferdige produktet slik ut:

En kort repetisjon:

Spesialikonene kan brukes sammen med parenteser for å lage kompliserte elementtypedeklarasjoner som i DTD-en nedenfor, hvis formålet er å vise kontaktinformasjon fra dag til dag:

Personen som denne listen viser informasjon om, kan på en gitt dag være på kontoret, hjemme eller på forretningsreise. Hvert <kontaktinfo>-element kan derfor omfatte én av følgende informasjonslister, med underelementer i den angitte rekkefølgen:

• Dato, et kontortelefonnummer, null eller flere numre til kontortelefakser, e-postadressen og ingen eller én melding.
• Dato, ett eller flere telefonnumre privat og eller numre til personsøkere, null eller flere telefaksnumre privat, e-postadressen og ingen eller én melding.
• Dato, ett eller flere telefonnumre og eller personsøkernumre mens du er på reise, null eller flere telefaksnumre mens du er på reise, e-postadressen og ingen eller én melding.

Det er mulig du vil skrive XML-dokumentene på en slik måte at de lett kan oversettes til HTML-format. I så fall vil du kanskje ta med koder som for eksempel <BR> og <HR> i XML-filen med tanke på bokstavelig oversettelse til HTML-filen.

Du kan egentlig ikke gjøre dette i XML, fordi alle elementer må ha en sluttkode. Det du imidlertid kan gjøre, er å lage såkalte EMPTY-koder som en XML-til-HTML-tolk siden kan oversette til de riktige kodene. Hvis du for eksempel vil lage <HR>-koder, setter du inn følgende linje i DTD-en:

Hvis du skulle bruke denne koden, kunne du f.eks. sette inn følgende linje i XML-filen:

Du kan ikke la koden stå som «<HR>», fordi alle XML-koder må enten ha en sluttkode eller avsluttes med en skråstrek. I dette tilfellet er det imidlertid greit, for en XML-til-HTML-tolk skal kunne konvertere <HR/> til <HR>.

EMPTY-koder brukes ofte til bilder. URL-en til bildedata lagres i et av attributtene til EMPTY-koden. Du kan lese mer om dette under «Definisjon av attributter» i dette kapitlet.

En tegnreferanse er en måte å representere Unicode-tegn på i analyserte tegndata. Syntakes for tegnreferanser er slik:

Hvis du for eksempel skal sette inn valutategnet for euro foran tallet 500 i et <beløp>-element, kan du gjøre slik (tegnreferansen står med halvfete typer):

Det er XML-behandlerens oppgave å sette inn riktig Unicode-tegn i stedet for tegnreferansen i det endelige produktet.

En entitetsreferanse er en liten bit med tekst som representerer noe annet, f.eks. et tegn, en tekststreng, en XML-fil som er lagret eksternt, eller en binær fil (bilde eller lydfil). Det finnes fem ulike typer entitetsreferanser:

• Analyserte, interne entitetsreferanser til representering av tekststrenger som ofte brukes på nytt
• Analyserte, eksterne entitetsreferanser brukes til å referere til tektsfiler som er lagret eksternt, og som inneholder analyserbare data
• Ikke-analyserte, eksterne entitetsreferanser brukes ofte til å referere til binære filer som f.eks. bilder, regneark og lyd
• Interne parameterentitetsreferanser til representing av kodedeklarasjoner som ofte brukes på nytt i DTD-er (alltid analyserte)
• Eksterne parameterentitetsreferanser brukes til å referere til tekstfiler som er lagret eksternt, og som inneholder analyserbare data fra DTD-er (alltid analyserbare)

Disse entitetsreferansetypene beskrives i detalj nedenfor.

Hva er forskjellen på en entitet og en entitetsreferanse? En entitetsreferanse er «stenografien» som du setter inn i et XML-dokument for å representere en entitet. En entitet er innholdet som erstatter entitetsreferansen når XML-dokumentet behandles.

Analyserte, interne entitetsreferanser

En analysert, intern entitetsreferanse er praktisk talt «stenografi» for en tegnstreng som du har tenkt å bruke ofte i et gitt XML-dokument. Formatet for deklarering av en analysert, intern entitetsreferanse i en DTD er som følger:

La oss for eksempel si at du lager et XML-dokument som inneholder en liste over medarbeidere og litt informasjon om hver enkelt medarbeider. Posten for hver enkelt medarbeider må ha med setningen «Antall år i firmaet:», etterfulgt av et tall. I stedet for å skrive inn setningen gang etter gang for hånd, kan du lage en analysert, intern entitetsreferanse for setningen i dokumentets DTD, i følgende eksempel:

Hvis vi skal bruke den analyserte, interne entitetsreferansen «år» i XML-dokumentet, kan vi gjøre følgende:

Når dette <medarbeider>-elementet behandles, utvider XML-behandleren den analyserte, interne entitetsreferansen, slik at du får følgende XML:

I XML finnes det fem analyserte, interne entitetsreferanser som allerede er definert. I motsetning til alle andre analyserte, interne entitetsreferanser, utgjør disse en del av XML-spesifikasjonen og trenger derfor ingen deklarasjon.

La oss anta at du skal bruke større-enn-tegnet (>) i innholdet til et XML-dokument. Som du allerede vet, brukes større-enn-tegnet til å angi sluttkoden i XML. For at ikke XML-behandleren skal bli forvirret, kan du bruke «&gt;» i stedet for større-enn-tegnet når det er nødvendig. Hvis du for eksempel skal formidle setningen «helheten > summen av delene i helheten» i en XML-fil, kan du gjøre følgende:

Bruken av analyserte, interne entitetsreferanser begrenses av tre faktorer:

• Du må deklarere en analysert, intern entitetsreferanse før du bruker den (med unntak av de fem som er oppgitt ovenfor).
• Du kan bruke en analysert, intern entitetsreferanse i elementinnhold og i attributtverdier.
• Du kan bruke en analysert, intern entitetsreferanse inni en annen analysert, intern entitetsreferanse, forutsatt at dette ikke innebærer en referanse med ringvirkning. Det er for eksempel ikke tillatt å bruke analysert, intern entitetsreferanse A i analysert, intern entitetsreferanse B hvis analysert, intern entitetsreferanse B også brukes i analysert, intern entitetsreferanse A.

Analyserte, eksterne entitetsreferanser

Med en analysert, ekstern entitetsreferanse kan du inkludere innhold som er lagret i en ekstern tekstfil. Analyserte, eksterne entitetsreferanser skal deklareres i DTD-en på én av følgende måter:

I det første eksempelet kan du bruke URL-en til en bestemt fil. Det andre eksempelet gjør bruk av navnet til en ressurs, som igjen kanskje peker mot en URL. Den etterfølgende URL-en er en «reserve»-URL som bare brukes hvis navnet ikke kan tydes.

Analyserte, eksterne entitetsreferanser kan brukes til å dele innhold mellom XML-filer. Her ser du et eksempel på et fullstendig XML-dokument der innholdet er lagret i en tekstfil kalt «minFil.txt» på web-stedet til Quark™:

Dette er praktisk, fordi innholdet i «minfil.txt» nå kan brukes i andre XML-filer.

Hvis det brukes eksterne entitetsreferanser i et dokument, skal attributtet «standalone» (frittstående) i XML-deklarasjonen endres til «no».

Uanalyserte, eksterne entitetsreferanser

Hva gjør du hvis du vil referere til et bilde, regneark, en lydfil, HTML-fil eller annen fil som ikke har XML-format, i et XML-dokument? Du kan ikke bruke en analysert, ekstern entitetsreferanse, fordi XML-behandleren da vil prøve å analysere binærfilen og dermed forårsake feil.

Problemet kan unngås ved å tilføye en notasjon i slutten av den eksterne entitetsreferansen. En notasjon gir XML-behandleren ganske enkelt beskjed om ikke å analysere målfilen, og angir filtypen. Formatet for deklarering av en notasjon i en DTD er som følger:

Hvis du for eksempel skal lage en forbindelse mellom JPEG-filer og Adobe® Photoshop®, kan du lage en notasjon som denne i DTD-en:

Hvis du skal bruke en notasjon i en deklarasjon for en ekstern entitetsreferanse, bruker du følgende syntaks:

Hvis du for eksempel skal lage en entitet kalt «mittBilde», som peker mot en URL med en JPEG-fil, kan du bruke følgende kode:

Du kan også bruke PUBLIC-syntaksen med notasjoner. Da spesifiserer du først et offentlig notasjonsnavn og deretter en URL som reservenotasjon:

Andre måter å referere til eksterne filer på: Uanalyserte entitetsreferanser er ikke den eneste måten å referere til eksterne filer på i XML-filer uten å måtte angi at de skal analyseres. Du kan også lagre URL-en til en slik fil som vanlig element- eller attributtinnhold. I det første eksempelet nedenfor er referansen til en URL for en bildefil tatt med i elementinnholdet, mens eksempel nummer to refererer til den samme URL-en i attributtinnholdet.

Det er helt opp til deg om du vil referere til filer som ikke er i XML-format, ved hjelp av ikke-analyserte entitetsreferanser, elementer eller attributter. Alle metodene fungerer like godt så lenge programmet som behandler XML-dokumentet, kan lese URL-er.

Interne parameter-entitetsreferanser

Hvis du vil lage en entitetsreferanse som bare brukes i en bestemt DTD, må du lage en parameter-entitetsreferanse. En intern parameter-entitetsreferanse ligner svært på en analysert, intern entitetsreferanse, bortsett fra at den starter med % i stedet for &, både i deklarasjonen og når du bruker den:

Du kan bruke interne parameter-entitetsreferanser i det eksterne delsettet til en DTD på samme måte som du bruker analyserte, interne entiteter i et XML-dokument. Her har vi for eksempel brukt en intern, parameter-entitetsreferanse som en forkortet måte å referere til en innholdsmodell som beskriver navnet på en person på:

Dette er praktisk fordi det gjør det lettere for deg å endre definisjonen av alle typer navn samtidig. Hvis du deretter skulle få bruk for å lagre mellomnavnet til alle arbeidsgivere, medarbeidere og kunder, kunne du endre den interne parameter-entitetsdeklarasjonen ovenfor til følgende:

Vær oppmerksom på at denne typen interne parameter-entitetsreferanser bare kan brukes i det eksterne delsettet til en DTD.

Eksterne parameter-entitetsreferanser

En ekstern parameter-entitetsreferanse er nesten lik en analysert, ekstern entitetsreferanse, bortsett fra at den starter med % i stedet for &, både i deklarasjonen og når du bruker den. I de neste to linjene (hentet fra det interne delsettet i et XML-dokument) lages det først en entitetsreferanse som henviser til en ekstern DTD kalt «standardTopptekst.dtd»; deretter blir den eksterne DTD-en inkludert i XML-filen:

Du kan lese mer om denne bruksmåten under «Bruk av standard DTD-er» i dette kapitlet.

Parameter-entitetsreferanser kan bare brukes inni en DTD.

Interne og eksterne parameter-entitetsreferanser kan brukes sammen. Du kan for eksempel bruke interne parameter-entitetsreferanser i det interne delsettet for å referere til entiteter som defineres i det eksterne delsettet. Dette er nyttig fordi du på den måten kan endre definisjonen på en entitet uten å endre det interne delsettet til XML-filer som bruker entiteten. Dermed kan du for eksempel ta med følgende deklarasjon i en tekstfil kalt «entitetsfil.txt»:

Deretter tar du med følgende i det interne delsettet av XML-dokumenter:

På denne måten kan du endre definisjonen på entitetsreferansen navnentitet i et ubegrenset antall XML-dokumenter ved bare å gjøre endringen i filen «entitetsfil.txt».

I tillegg til innhold kan elementer også innholde attributter (se «Mer om XML» i dette kapitlet). Det er ikke enighet om hvilken funksjon attributter har, men i denne sammenheng tar vi utgangspunkt i at et attributt skal inneholde elementinformasjon som er av betydning for XML-behandleren, uten å være en del av innholdet i selve XML-filen.

La oss for eksempel si at du bruker XML til å føre en bokliste som skal vises på et web-sted. Listen kan vises på to ulike måter: komplett liste med alle bøker eller liste med bare bøker som er tilføyd de siste 10 dagene. For at dette skal være mulig, må XML-dokumentet angi hvilken dato hver enkelt bok ble oppført.

Dette kan du gjøre ved å legge til delkoden <oppførtDato> til definisjonen av <bok>-koden, men datoen når en bok legges inn i systemet, er ikke akkurat informasjon om selve boken. Du velger i stedet å lage et attributt kalt «oppførtDato».

Syntaksen for attributtdeklarasjoner er som følger:

Hvis du så skal gi <bok>-elementet attributtet «oppførtDato» med en standardverdi på «01.01.2000», legger du til følgende linje i DTD-en:

Hvis dette attributtet deretter skal brukes i et <bok>-element, bruker vi ganske enkelt et attributtpar på følgende måte:

Dette attributtet gir XML-behandleren informasjonen den trenger for å kunne vise bøkene på grunnlag av datoen da bøkene ble oppført.

Nødvendige, underforståtte og faste attributter

Alle attributter kan være nødvendige (REQUIRED), undersforståtte (IMPLIED) eller faste (FIXED). En nødvendig attributt-standard angir at elementet må inneholde dette attributtet. Denne attributtdeklarasjonen angir for eksempel at hvert <bok>-element må ha med et attributt av typen «oppførtDato»:

En underforstått attributt-standard betyr at XML-forfatteren selv kan bestemme om elementet skal inneholde dette attributtet eller ikke. Attributtdeklarasjonen nedenfor angir for eksempel at hver <bok> både kan ha med og være uten attributtet «oppførtDato»:

En fast attributt-standard betyr at attributtet må ha en bestemt verdi for hvert element. I denne attributtdeklarasjonen angis det for eksempel at hver <bok> må ha verdien «11.11.1998» for «oppførtDato»:

I dette eksempelet antar XML-behandleren at hvert <bok>-element har et attributt av typen «oppførtDato» der verdien er lik «11.11.1998,» selv om attributtet er utelatt.

Hvis en attributtdeklarasjon har en standardverdi uten å angi #REQUIRED, #IMPLIED eller #FIXED, bruker XML-behandleren attributtets standardverdi når attributtet er utelatt.

Attributt-typer

Nøkkelordet CDATA i vårt eksempel på en attributtdeklarasjon betyr at vi vil at dette attributtet skal inneholde tegndata. CDATA er imidlertid bare ett av alternativene for attributt-type. Her følger hele listen.

• Attributtet CDATA kan inneholde tegndata og entitetsreferanser.
• Attributtet ENTITY må inneholde navnet på en ikke-analysert entitet som deklareres i DTD-en. (Du kan lese mer om entiteter under «Bruk av entitetsreferanser» i dette kapitlet.) Du kan for eksempel bruke et ENTITY-attributt til URL-en til et grafisk bilde:

• Attributtet ENTITIES må ha med navn på én eller flere ikke-analyserte entiteter som deklareres i DTD-en. Listen over entiteter må atskilles med mellomrom. Eksempel:

• Attributtet enumerated list kan inneholde ett enkelt navn fra en navneliste i parentes. (Her betyr «Navn» at alle verdiene i listen må følge navnekonvensjonene som XML-elementer.)
• Når du skal bruke attributtet «enumerated list», setter du ganske enkelt inn listen med navn i attributtdeklarasjonen i stedet for et nøkkelord. I den neste linjen er det for eksempel spesifisert at attributtet «salgsStatus» for <bok>-elementet bare kan inneholde «Nedsatt_pris» eller «Vanlig_pris»:

• Attributtet ID spesifiserer at hvert element må ha en entydig verdi (hvis en slik verdi er tilgjengelig) for det aktuelle attributtet. Eksempel:

Den deklarerte standarden for et ID-attributt må være #IMPLIED eller #REQUIRED. Ingen elementer kan ha mer enn ett ID-attributt.

• Attributtet IDREF må «peke på» et annet element i XML-dokumentet som har en en ID-attributtverdi. Eksempel:

• Verdien for et IDREFS-attributt består av en rekke IDREF-attributter, atskilt med mellomrom.
• Verdien for et NMTOKEN-attributt kan omfatte en rekke tegn, også bokstaver, tall, understrekinger, punktum og så videre. Mellomrom kan imidlertid ikke brukes. Det neste eksempelet er ikke gyldig, fordi det er brukt mellomrom i uttrykket «Mitt lokale navn»:

• Et NMTOKENS-attributt er det samme som et NMTOKEN-attributt, bortsett fra at attributtverdien kan være en liste med NMTOKEN-attributter atskilt med mellomrom.

• Et NOTATION-attributt må inneholde ett eller flere XML-notasjonsnavn fra DTD-en. Med dette kan du lage notasjoner som spesifiserer programmer for bildevisning og filmavspilling, og deretter bruke et elementattributt for å være sikker på at riktig program brukes til en gitt del av innholdet. Eksempel:

Denne informasjonen forteller programmet som behandler XML, at det kan bruke programmet PictureViewer til å åpne bildefilen med, og MoviePlayer til å åpne filmfilen med.

Ingen elementer kan ha mer enn ett NOTATION-attributt.

• Attributtet enumerated NOTATION må inneholde ett eller flere XML-notasjonsnavn fra DTD-en, angitt som en liste i parentes. Du kan for eksempel lage notasjoner som spesifiserer flere programmer for bildevisning og filmavspilling, og deretter bruke et elementattributt for å være sikker på de rette programmene brukes til en gitt del av innholdet. Dette kan se slik ut:

I stedet for å lage ett element for både bilder og film, har vi her laget to separate elementer, <bilde> og <film>. For hvert av disse elementene spesifiserer DTD-en to ulike programmer som kan brukes til å vise filen med. Hvilket program som benyttes, bestemmes av den enkelte <element>-koden i XML-brødteksten.

Attributtet xml:lang

Med attributtet «xml:lang» kan du angi hvilket språk som skal brukes i et element. Attributtet skal inneholdet ett av følgende:

• Språkkode på to bokstaver i henhold til definisjon i ISO 639, eventuelt etterfulgt av en bindestrek og en deltype (vanligvis en landskode)
• IANA-registrert språknummer, med prefikset «i-» eller «I-»
• Brukerdefinert språkkode med prefikset «x-» eller «X-»

Vær oppmerksom på at disse attributtene ikke allerede er definert. Du må deklarere dem før de kan brukes.

Når du skal angi språket du vil bruke, tilordner du bare koden for det aktuelle språket. I den neste DTD-en er det tatt med et «xml:lang» element, og elementet i XML-brødteksten spesifiserer det engelske språket med ISO 639:

Du kan spesifisere deltyper for språk ved å tilføye en utvidelse forbundet med bindestrek til språknavnet. I det neste eksempelet har vi angitt internasjonal engelsk (anvendt i Storbritannia og Nord-Irland) i stedet for amerikansk engelsk:

Attributtet xml:space

Med attributtet «xml:space» kan du fortelle programmet som behandlet XML at det skal la alle blanktegn for et element og dets underledd stå uforandret (med mindre ett av elementets underledd tilbakestiller koden). Denne DTD-en spesifiserer for eksempel et «xml:space»-attributt, og elementet i XML-brødteksten angir dette attributtet til «beholde» for dette elementet og dets underledd:

Du kan bruke koden <![IGNORE[]]> hvis du vil fortelle XML-analysatoren at den skal overse et stykke med tekst i en ekstern DTD. Her et et eksempel:

Du kan be XML-analysatoren analysere teksten mellom kodene ved ganske enkelt å endre IGNORE til INCLUDE på følgende måte:

Som tidligere nevnt, kan du referere til en ekstern DTD i DOCTYPE-deklarasjonen til et dokument på følgende måte:

Hvis du bruker en DTD som er godkjent av et organ som f.eks. International Standards Organization (ISO), kan du bruke entitetsreferansen PUBLIC til å angi navnet på en alminnelig tilgjengelig kopi av DTD-en. I slike tilfeller må du også oppgi URL-en til en SYSTEM DTD-fil, slik at det finnes noe å falle tilbake på hvis PUBLIC-kopien av DTD-en ikke er tilgjengelig.

Noen ganger kan det være aktuelt å lage separate DTD-er til å definere ulike deler av et dokument med. Din organisasjon bruker for eksempel én DTD til all informasjon i topptekst og bunntekst i alle XML-filer, og andre DTD-er til brødteksten i dokumenter som lages i ulike deler av organisasjonen. Det er mulig å imøtekomme slike behov ved å lage én enkelt ny DTD som inneholder de ulike DTD-ene du trenger, og som spesifiserer en rekkefølge for DTD-enes rotelementer. Eksempel:

I dokumenter som bruker denne DTD-en, er <OSSRappDok> rotelementet, og <standardTopptekst>, <OSSRapp> og <standardBunntekst> de påfølgende underelementene. Et slikt dokument med denne DTD-en kan se slik ut:

I enkelte arbeidssituasjoner kan det tenkes at det brukes DTD-er som er nesten identiske for en brukergruppe, men som trenger små justeringer for å kunne brukes i en bestemt avdeling eller arbeidsgruppe. Dette lar seg lett gjøre. Det er bare å inkludere DTD-en i DOCTYPE-deklarasjonen og deretter tilføye de nødvendige kodedeklarasjonene i det interne delsettet.

Det er ikke mulig å omdefinere et element som allerede er definert i den eksterne DTD-en, men du kan omdefinere entiteter og standardverdier for attributter.

Hvis du skriver XML-dokumentene i en tekstbehandler, kan du lese gjennom den tilhørende DTD-en for å kontrollere at du følger reglene. Det er likevel ikke mulig å være helt sikkert på at alle reglene er fulgt før det utføres en gyldighetskontroll av XML-dokumentet opp mot DTD-en med et program som kalles en gyldighetsanalysator. Gyldighetsanalysatoren leser gjennom DTD-en og kontrollerer XML-filen for å være sikker på at den følger reglene i DTD-en. En god gyldighetsanalysator gir også beskjed om eventuelle problemer.

Husk at når du skal foreta en gyldighetskontroll av et XML-dokument i forhold til en bestemt DTD, trenger du en XML-gyldighetsanalysator, og ikke en vanlig XML-syntaksanalysator. Det finnes mange XML-analysatorer som kan kontrollere hvorvidt en XML-fil er godt formulert; langt færre utfører gyldighetskontroll av XML-filen.

Du finner en kort oversikt over DTD-funksjoner og -konvensjoner i tillegg B, «Grunnbegreper om DTD», i kapittel 7, «Tillegg».

Bør du lage en ny DTD som er spesialtilpasset til behovene i din organisasjon? Eller bør du bruke en standard DTD som vil spare deg for tid du ellers ville ha brukt til utvikling av en DTD, og som kan gjøre det lettere å utveksle informasjon med andre organisasjoner innen samme bransje?

Det finnes fordeler og ulemper med begge løsningene. Hvis du lager en egen DTD fra grunnen av, har du fullstendig kontroll med strukturen i DTD-en og oppdateringene av den. Du står imidlertid overfor en betydelig investering med hensyn til tid og krefter, og du må være svært nøye med å vurdere behovene til alle som skal bruke DTD-en. Bruker du en standard DTD, behøver du ikke å tenke på selve utviklingen av DTD-en, men i stedet følge DTD-ens konvensjoner og holde deg til strukturen som defineres i den.

Hvis du har tenkt å utveksle informasjon med andre organisasjoner, kan det være lurt å bruke en standard DTD. Bruk av en standard DTD kan bidra til at informasjonsutvekslingen er problemfri, og at informasjonen du koder kan brukes i andre sammenhenger. Dette er nettopp en av grunnene til at XML ble utviklet: Å bidra til standardiseringen av formater som informasjon lagres og utveksles i.

Standard DTD-er har imidlertid sine ulemper. To organisasjoner kan nemlig ha helt ulike behov, selv om de i hovedsak arbeider med den samme informasjonen. Standard DTD-er kan riktignok tilpasses til å brukes i en organisasjon, men da er en del av hensikten borte, nemlig å sikre at informasjonen lagres med like formater organisasjonene i mellom.

Hvorvidt du kan bruke en standard DTD, avhenger av flere faktorer.

Finnes det en standard DTD i din industrigren?

Du kan finne svar på dette spørsmålet ved å søke etter standard DTD-er på World Wide Web. To gode utgangspunkter er www.schema.net og www.xml.org.

Hvis det finnes en standard DTD innen bransjen, oppfyller den behovene du har?

• Hvis du finner en standard DTD som ser ut til å kunne brukes i din organisasjon, se nøye over den før du tar den i bruk. Hvis du benytter en DTD som ikke egner seg til ditt bruk, kan dette føre til alvorlige problemer. En uegnet DTD kan for eksempel:
• Tvinge forfattere til å bruke ukjente og uanvendelige strukturer
• Pålegge forfatterne å tvinge data inn i uegnede elementer
• Begrense forfatternes mulighet til å indeksere og søke i informasjon
• Gi for stor frihet, som kan føre til feil koding
• Gjøre det vanskelig å konvertere til andre formater
• Tvinge databehandlingsprogrammene til å bli altfor kompliserte
• Påføre store utgifter hvis DTD-en i siste instans viser seg å være ubrukelig, slik at all data må konverteres til et annet format

Tenk nøye gjennom dette. Hvis DTD-en du velger ikke oppfyller de aktuelle behovene, vil antakelig den samlede effekten av eventuelle mangler øke etter hvert.

Hvis det ikke finnes noen standard DTD innen bransjen, er en DTD under utvikling?

• Hvis du ikke finner en standard DTD som passer til behovene til din organisasjon, kan det kanskje være aktuelt å finne ut om andre i bransjen er i ferd med å utvikle en standard DTD. I så fall kan din organisasjon få muligheten til å påvirke utviklingen av DTD-en. Deltakelse i utviklingen av en DTD som skal bli standard i industrien, kan bidra til at du unngår problemer som kan oppstå ved å ta i bruk en DTD som ble utviklet av noen som ikke er kjent med dine problemer.

Noen organisasjoner velger å bruke en standard DTD, men endre den slik at den passer til organisasjonens behov. University of California Press tok for eksempel utgangspunkt i DTD-en «book» (ISO-standard med SGML-format) og gjorde en rekke justeringer i den, blant annet ved å legge til elementer som gjorde det mulig å lagre informasjon som underoverskrifter til kapitler, og kapittelspesifikke linjer med forfatternavn. ISO («International Standards Organization» [Internasjonal standardorganisasjon]) gir retningslinjer for hvordan DTD-ene kan endres, slik at den nye DTD-en du lager, likevel er relativt standardisert.

Men hva skjer hvis du skal utveksle informasjon med andre organisasjoner som bruker den originale DTD-en slik den var før du endret den? Enkelte organisasjoner velger å lage verktøy som kan konvertere dokumenter som følger de endrede DTD-ene, til dokumenter som følger den originale DTD-en. En slik løsning gir mange av de fordelene som en spesialtilpasset DTD gir, samtidig som du kan utveksle data med andre organisasjoner innen bransjen.

Med avenue.quark kan du bruke en DTD til å hente ut strukturert innhold fra QuarkXPress Passport-dokumenter og lagre innholdet i filsystemet eller i en database. I neste avsnitt finner du et eksempel på hvordan prosessen fungerer i en gitt situasjon.

La oss si at organisasjonen din har laget mange tekniske dokumenter i QuarkXPress Passport-format, og innholdet skal nå eksporteres til XML-format og lagres i en database der kundene kan hente informasjonen på Internett. Alle tekniske dokumenter bruker samme maldokument og tekst-mal i QuarkXPress Passport.

Før du kan hente ut innholdet i de tekniske dokumentene i et strukturert format, må du ha en struktur som innholdet skal settes i. Det er dette DTD-en brukes til.

Du kan lese mer om DTD-er under «Bruk av DTD-er» i dette kapitlet.

Du har to muligheter når du skal skaffe en DTD som kan brukes med avenue.quark:

• Velg en eksisterende XML DTD. I skrivende stund finnes det flere standard DTD-er for XML, og etter hvert som bruken av XML blir mer utbredt, får du tilgang til flere. Hvis du velger å gjøre det på denne måten, bør du foreta en nøye vurdering av DTD-en du har tenkt å bruke. Velger du en uegnet DTD, kan du gjøre livet surt for dem som skal bruke den.
• Lag din egen DTD. Les gjennom «Bruk av DTD-er» i dette kapitlet, analyser deretter nøye de ulike delene som utgjør et teknisk dokument, og lag til slutt en tilsvarende DTD. Dette kan være tidkrevende, men det lønner seg hvis den ferdige DTD-en passer til formålet. Det er vanligvis personer i redaksjonen eller administrasjonen som velger DTD.

Lag et nytt XML-dokument i avenue.quark og angi DTD-en du valgte i trinn 1. Eventuelle obligatoriske elementer i DTD-en settes automatisk inn i XML-dokumentet.

Paletten til XML-arbeidsområde for et nytt XML-dokument

En av de spesielle funksjonene i avenue.quark er regelbasert koding. Med regelbasert koding kan du opprette et koderegelsett som for eksempel forteller avenue.quark at et avsnitt som bruker tekstmalen «Overskrift», vanligvis skal kodes som <Tittel>. Du kan også bruke koderegelsett til å angi hvordan bestemte tekstmaler for tegn, tekstfarger og lokale formateringsstiler skal kodes. (Du kan lese mer om koderegelsett i kapittel 5, «Koderegelsett».)

Lagre XML-dokumentet som et maldokument med navnet «Tekniskdokument.xmt.» Maldokumentet inneholder DTD-en for det tekniske beskrivelsen og kodereglsettet som du laget i trinn 3. Dette maldokumentet kan nå brukes til å lage så mange XML-filer med tekniske beskrivelser du bare vil, alle på én eller flere datamaskiner.

Når du lager et nytt XML-dokument i avenue.quark, må du først velge et maldokument som det nye XML-dokumentet skal baseres på. Dette velger du i listen Maldokument. I dette eksempelet bruker vi «Tekniskdokument.xmt» fra trinn 4.

Maldokumentet Tekniskdokument.xmt gjør det lett å kode et teknisk dokument fra QuarkXPress Passport.

Når du skal utføre regelbasert koding, bruker du tastkombinasjonen Command+dra (Mac OS) eller Ctrl+dra (Windows) på boksen som inneholder den tekniske dokumentasjonen, til <tekniskdokument>-elementet på rullelisten XML-tre. Dermed koder avenue.quark automatisk dokumentet etter reglene i koderegelsettet.

Regelbasert koding innebærer at du trykker på Command og drar (Mac OS) eller Ctrl og drar (Windows) boksen til riktig element i listen XML-tre. Avenue.quark bruker koderegelsettet til å kode så mye av innholdet som mulig.

Noe av den tekniske dokumentasjonen er forhåpentligvis klar etter at du har utført regelbasert koding. Annen teknisk dokumentasjon har derimot kanskje mer innhold som må kodes manuelt, eller innhold som kan kodes på mer enn én måte. Slike tilfeller løser du ved å dra det aktuelle innholdet til det rette elementet i paletten XML-arbeidsområde.

Så snart innholdet i den tekniske dokumentasjonen har fått XML-format, kan du bruke en rekke forskjellige verktøy til å legge innholdet ut på Internett. Du kan for eksempel presentere det som rene XML-koder, slik at innholdet kan vises med nyere Web-lesere, f.eks. Microsoft Internet Explorer 5.0. XML-kodet innhold kan også brukes på en rekke andre måter, alt fra elektronisk informasjonsutveksling til produksjon av trykte dokumenter.